System and method for recording voice and the data entered by a call center agent and retrieval of these communication streams for analysis or correction

ABSTRACT

The invention provides for a communications recording and analysis system including means for recording one or more communication streams, means for identifying the recorded stream, means for retrieving the content of said recordings by identifier tags, and wherein additional real-time information is inferred from analysis, in real-time or later, of keystrokes entered at a computer/terminal handling the interaction, and/or computer mouse actions, and/or internet traffic emanating from, or terminating at, any one or more of a number of computers/terminals handling the interaction, and/or the words and/or prosody spoken during the interaction is recorded. Furthermore graphical display means are provided such that the presentation of call flow recording is in the form of a direct graph showing the progress of the calls through the various states and transitions.

TECHNICAL FIELD

The present invention relates to a system and method for analysingcommunication streams.

DESCRIPTION OF THERELATED ART

Currently many commercial entities perform substantial amounts of theirbusiness via telephone or Internet contact with their customers. Theanalysis of such contact can therefore help businesses to improve thequality and efficiency of their services, and assist with customerretention and, ultimately, profitability. Attempts have been madepreviously to achieve such analysis in a satisfactory manner and to asatisfactory degree. For example, many businesses have, for some time,recorded some of their communications streams e.g. telephone callsbetween their staff and their customers. Traditionally this was done tosatisfy regulatory requirements or to help resolve disputes. Morerecently, the emphasis has moved towards the reviewing of theseinteractions from a quality perspective. This is intended to identifygood and bad aspects of particular calls with a view to improving thelevel of customer service given. Recently, for example, recording theactivity on a PC screen has been undertaken to improve the completenessof the review procedure with the reviewer able to see how accuratelystaff are entering information received via the telephone.

Also, it has been known to employ Call Detail Recording (CDR) systems toprevent perceived abuse of telephone systems and to apportion costs tothe department or individual making the calls.

Originally such records were printed out directly from the PrivateAutomatic Branch Exchange (PABX) onto a line printer. Later, systemswere designed to store this information in a database allowing moresophisticated reporting and searching for calls on the basis of one ormore of the stored call details. More recently, Computer TelephonyIntegration (CTI) interfaces have been provided that give thisinformation in real-time, during the call.

Further, several systems currently exist that use call recording incombination with CDR or CTI and a database application in order toperform routine monitoring of calls with the intention of identifyingweaknesses in individual Customer Service Representatives (CSRs).Typically a small percentage of the CSR calls are reviewed and “scored”against a set of predetermined criteria to give an indication of thequality of that particular member of staff.

Within a call-centre environment, it should also be noted that ratherthan simply using standard PC office automation applications whendealing with customers, staff in most call centres use increasinglysophisticated applications that help them to handle the calls moreefficiently and effectively. Helpdesk applications and telemarketingcall scripting applications are examples of such applications. Most suchapplications share the following characteristics:

-   -   (i) they guide the staff member through the interaction, either        explicitly suggesting questions to ask or implicitly e.g. by        presenting a form with various fields to be filled in with        details to be gleaned from the customer; and    -   (ii) the progress of the call is, to some degree, dictated by        the answers given during the call.

As an example, a service call to a help desk may flow through thefollowing stages:

-   -   (i) take customer details and verify maintenance contract is up        to date;    -   (ii) take details of the problem being experienced;    -   (iii) attempt to resolve using appropriate set of diagnostic        questions;    -   (iv) if not solved, agree schedule for engineer to visit; and    -   (v) give customer a problem reference number.

Within each of the above main stages there will be one or moresub-stages e.g. (i) (a) caller's name (i) (b) zip code etc.

Current systems employed for CSR quality monitoring require the manualreview of calls in order to determine a quality “score”. This prohibitsthe review of more than a few percent of all calls and the accuracy ofthe human scoring process and its objectivity are at best questionable.When coupled with a small sample size of typically only a few calls perCSR per week, the resultant scores offer a limited degree of qualitymonitoring. Also there are only a few aspects of the call that allow forautomated scoring. The most common such aspect is the call durationwhich, for a known telemarketing script, should be within a known range.A portion of the overall score (perhaps 5%) may be allocated to such anaspect of the call.

Call centre management seeks to handle calls as efficiently as possibleyet take advantage of cross-selling and up-selling opportunities whilstthe customer is already on the line. To this end, the way in which callsare handled within the call centre is of critical importance to theoverall efficiency and profitability of the operation. As thesophistication of call handling systems and processes increases, so thecomplexity of the call flow designs increases such that it is verydifficult to fully test and exercise these “scripts” prior to, or evenduring, their full-scale deployment. Sophisticated scripts may require ahundred pages or more of documentation including the “call flow diagram”and the associated questions and forms presented to the CSR. With manyhundreds or even thousands of possible paths through such a script, anyone CSR will not have sufficient experience of many particular routesthrough the script to allow for the objective evaluation of theeffectiveness or otherwise of, for example, the suggested way to handlea particular objection raised during a sale.

Current systems typically store details of each call in a relationdatabase typically with one record of more or less fixed structure percall. These details may include indications of the type of call, the“completion code”, or whether a particular option was chosen or not etc.More advanced systems cater for the cases where a single “call” actuallycontains more than one transaction (e.g. request a quotation for twodifferent insurance policies). This is typically done by subdividing thecall into two or more parts each of which then has a database recordassociated with it.

Existing systems use one or more database records per call and theidentification of calls normally requires that the user determine inadvance which aspects of the call's progress are to be stored. Timinginformation stored is often limited to total call duration. The relativetime between different points in the call is difficult to determine.Calls that “loop” through the same part of the script several times arenot well described by a single database record.

It has also been appreciated that customers and potential customersgenerally much prefer a “warm call” to a “cold call” i.e. a call wherethe caller obviously has taken the trouble to find out about acustomer's previous dealings with their business rather than merelyselecting the name from a list without any knowledge of the particularcustomer's details; many of which may already have been givenpreviously.

Many businesses now proactively call their customers on a regular basisto try and “cross-sell” or “up-sell” with other products that they havedetermined may be of interest to the customer.

However, currently, where a follow-up call is to be made as the resultof a previous call perhaps made several months earlier there is oftenlittle information available to the CSR responsible for the follow-upcall. For example, a routine call to all mortgage customers may includethe question “Have you reviewed your life insurance cover recently”?.According to the answer given, the customer may be placed on a list fora follow up call the next time a new life insurance policy is launched.At the time of the original call, the CSR will likely do no more thantick a “Yes/No/Maybe” option.

When the customer is called some months later, all that the new agentknows is that the customer previously said they may have been interestedand the factual details presented about the customer's previouspurchasing history. They do not know exactly how or in what tone ofvoice the customer responded several months earlier.

Additionally, such systems are open to abuse by the CSRs as they may berewarded, or at least measured, by the number of such follow-up leadsthey record. Hence there is a temptation for anything other than apoint-blank “No” to be recorded as a “Maybe”.

It is also acknowledged that, in order to improve business processes,train CSRs and identify problems, there is a desire to identifyindividual calls or sets of calls which are handled particularly well orbadly or that highlight deficiencies, opportunities, trends oranomalies.

Existing systems limit the selection criteria to those that can bederived solely from call details. These use individual database recordsassociated with each call to store data fields about each call. Theseare particularly inflexible and need to be designed prior to the query.For example, if a user identifies that they will want to search forcalls where the “Help” key was pressed, they could tag each call with abinary flag and set this to true as the help key is pressed. A moresophisticated solution would be to use a time field and store the timeat which the help key was pressed. However, if the user then wants tofind calls where “Help” was pressed twice or more, this known previousdatabase scheme proves inadequate.

When considering call-replay, and irrespective of the reason for wantingto replay a specific call, there is often a desire to listen to aparticular section of a call rather than the whole call. For example, aninsurance claims handler will want to confirm that a driver now known tohave a previous conviction disclosed this when asked during the initialpolicy quotation. Being able to jump directly to the portion of the callwhere the customer was asked this question avoids the need to browsethrough the whole call. Alternatively, a mail-order company CSR needingto correct an invalid address would like to jump to the part of theoriginal call where the address was given.

Current systems require users to either listen to the whole call or tojump around the call listening to snippets until they “home in” on therequired section. This is time consuming and prone to error.

Further it has long been possible to perform automated speechrecognition in an attempt to transcribe or at least to highlight keywords within telephone conversations. The capabilities of such systems(accuracy, tolerance of natural conversation speed, cost effectiveness)have been gradually improving during recent years.

To obtain maximum accuracy, currently employed algorithms are very CPUand memory intensive. It is unlikely that many customers will be able toafford to deploy full recognition across all conversations they record.

Simply applying generic recognition to the whole of a conversationrequires the recognition algorithm to infer the context and grammar fromthe conversation in order to refine its decisions as to which words itheard. This process is CPU intensive and less accurate than beingexplicitly told the current context of the conversation.

It will therefore be appreciated that the current schemes ofcommunication analysis are disadvantageously limited.

The present invention seeks to provide a system and method for analysingcommunication streams having advantages over known such systems andmethods.

SUMMARY

According to one aspect of the present invention there is provided asystem for communications recording and analysis including means forrecording one or more communication streams, means for identifying therecorded streams, means for retrieving the content of said recordings byidentifier tags and wherein additional real-time information relating tothe progress of the said communication streams is recorded.

Preferably, the communication streams and associated progress streamsare linked by means of a cross reference within respective call detailrecords in a database of recordings.

In one embodiment, the communication streams can be interleaved with thecall flow recordings and a composite stream is recorded.

Advantageously, the progress information may be inferred from analysis,in real-time or later, of keystrokes entered at a computer/terminalhandling the interaction.

Alternatively, the progress information may be inferred from analysis,in real-time or later, of computer mouse actions.

Yet further, the progress information may be inferred from analysis, inreal-time or later, of internet traffic emanating from, or terminatingat, any of a number of computers/terminals handling the interaction.

Additionally, the progress information may be inferred from analysis, inreal-time or later, of the words and/or prosody spoken during theinteraction.

It should be appreciated that the contents of the call flow data streammay be used to refine the recording and/or analysis of the mainstream(s).

Preferably, retrieval of specific sets of recordings may be performed byselection from the call detail records describing each of the recordingsand/or the presence, repeated presence or absence of specified events orcall states.

Advantageously, the criteria may include relative or absolute timinginformation.

Further, the presentation of the content of individual recordings may bein the form of a graphical display including bars and/or pictures andwherein the location, colour and/or size of which may be determined bythe recorded call flow recording.

In particular, the presentation of one or more call flow recordings maybe in the form of a directed graph showing the progress of the callsthrough the various states and transitions.

Also, the position, colour, labelling, texture and other graphicalattributes of the nodes and/or lines can be determined by the number ofcalls following that route; the time they spend in the various statesand/or other attributes derivable from the call flow recordings.

Still further, the display can be populated, and the graphicalattributes modified, in real-time to reflect the timing informationrecorded within the call flow recordings.

In particular, the speed of replay can be varied, for example, including“paused”, “forwarded” or “reversed” at any rate including “single-step”mode.

Also, the set of call flow recordings may be refined by selecting, forexample, via a double-click, a specific transition as discussed furtherlater.

Advantageously, specific nodes and/or transitions can be highlightedaccording to automatically or manually defined rules so as to drawattention to the presence or absence of particular call flow routes.

The invention is advantageous in that the ability to track the progressof the call through the various stages allows more criteria to besubsequently scored automatically and hence objectively. Sincecomputer-scoring can be easily and cost effectively achieved, it can beperformed economically on a much larger sample of the calls—often thefull 100%. For example, the time spent taking customer details should bewithin allowed ranges. Calls that did not result in the sale of product“X” should not have spent more than t seconds trying to sell thisproduct before moving on to other propositions. Calls should not occurwhere the customer had to go back and re-enter details that should havebeen picked up earlier. Such a system allows perhaps 20–30% of theoverall quality “score” to be determined automatically and thereforeobjectively and across all calls. This gives much better statisticalsignificance with less manpower.

With regard to call flow design and call centre management, theinvention can for example:

-   -   present N examples of calls following a specific path through        the call flow script e.g. a rarely exercised branch; and    -   further filter these calls according to more traditional call        detail records e.g. “Service calls for Model XYZ that ended        without problem resolution”

Having selected the set of calls of interest, these are then presentedto the user and this can allow them to:

-   -   review just a specified section of the call (e.g. answer to        question 143) without having to dip into the whole call to        determine the appropriate part of the call;    -   review the whole call so as to hear the required section in        context; and    -   see the timing information associated with the calls e.g. how        long spent in the specified section; how long between start of        sales pitch and this section etc.

Turning now to the personalisation of calls, the invention canadvantageously allow the few seconds of response to the relevantquestion to be retrieved efficiently without the user having to listento the rest of the call. Using this feature, two strategies can beadopted. First, all of the responses to the question can be reviewed bya dedicated individual or team prior to the campaign getting underway.

As they listen to all of the responses, they can (a) prioritise thecustomers from most to least likely to buy and hence choose which oneswill eventually be called and (b) ensure that the script that is to beused when the campaign starts includes answers to the issues likely tobe raised. Hence they can improve the effectiveness of the campaign andreduce the number of wasted calls that will be made. Note that feature(a) above requires all responses to be listened to, whilst feature (b)only requires that a statistically significant sample be reviewed.

Secondly, during the campaign, agents may be presented with the previousresponse either in audio form or in textual form (manually orautomatically transcribed). The former gives them the tonal andemotional content of the response but is less practical whereautodiallers are used to present calls to CSRs as soon as the customeranswers. Either approach lets them speak to the customer from a positionof advantage, knowing exactly how they reacted to the question when lastasked. Presenting the previous response first would allow the CSR todetermine whether it is worth placing the call or not.

By recording the detailed progress of the call along with the calldetails and call content, the system advantageously allows the user toidentify sets of “interesting” calls. Such calls might be thoseexhibiting the presence or absence of certain events within the calle.g. CSR requested “help” during the quotation process. This couldidentify CSR specific training needs or areas where all staff experiencedifficulty that could be improved.

Alternatively, or in addition, where one product was purchased butdetails of others were also given, it might be worth calling thecustomer soon to try again to sell them these other products.

Also, where the CSR had to return to a previous part of the script, thereason for this can be considered. For example, was a questionambiguous, a mistake made or did the customer change their mind?

Further, where less than 5 seconds was spent in the “confirmation”screen where customers should have the small print explained to them,this could suggest that the CSR was rushing on to the next call toofast.

Of course, poor typing skills might be indicated by excessivecorrections and slow data entry.

Efficient replay of calls can advantageously be achieved by recordingthe detailed progress of the call along with the call details and callcontent so that the system allows the whole call to be shown on aGraphical User Interface (GUI) with graphical indications of the currentstate of the call and significant events within the call. The user canthen choose which section(s) of the call to play by clicking on theappropriately marked points. Also, required segments of the call to bepresented in isolation and played individually or one after the other.

The present system, through monitoring and recording the progress of thecall along with the audio content of the call, advantageously allowsspeech recognition algorithms to be directed at only those sections ofconversations where maximum value is likely to be obtained. For example,no interpretation of the speech is undertaken whilst the customer'saddress is being taken. Likewise, interpretation can be concentrated onsections where sales objections are being handled or likely to behandled. Further, the algorithms can be directed in their selection oflikely words according to the context of the conversation. For example,if a CSR has tabbed to the “Destination” field on screen, the customeris therefore more likely to have said “Paris” than “Pairs”. Also, thealgorithm can be directed as to the likely speaker—whether CSR orcustomer. That is, where independent transmit and receive audio streamsare not available, the progress through the call can be used to identifywhich speaker is most likely to be talking.

The capabilities described above also allow the system to be used forthe following additional and advantageous purposes. Usability analysiscan determine how many keystrokes/mouse clicks were required to performthe most common functions and also identify the most common functions.Testing and Verification can also be achieved and used to find any callswhere an order was taken that had not previously taken the customerthrough the required explanatory text thereby identifying an invalidpath through the call flow script. CSR Quality Monitoring allows for theidentification of those CSRs that spend more, or less, time thanexpected in specific sections of the call flow process or that followcertain paths through the call flow more or less often than the norm.

BRIEF DESCRIPTION OF DRAWINGS

The invention is described further hereinafter, by way of example only,with reference to the accompanying drawings in which:

FIG. 1 is a block diagram of a recording and analysis system embodyingthe present invention;

FIG. 2 is a functional block diagram of a recorder such as that in FIG.1;

FIG. 3 is a functional block diagram of an Application ProgrammingInterface (API) for use within an embodiment of the present invention;

FIG. 4 is an illustration of a graphical representation of the progressof a call;

FIG. 5 is a flow diagram such as that displayed in accordance with anembodiment of the present invention to illustrate call progress; and

FIG. 6 is a further flow diagram derivable from the diagram of FIG. 5.

DETAILED DESCRIPTION

Turning first to FIG. 1, one or more datastream recorders 4 areconnected to speech transmission circuits 2 which in turn are typicallyconnected to a Private Automatic Branch Exchange (PABX) or similartelephony switching system 1. Connection is achieved by means of a highimpedance tap 3 which does not impact the normal use of the speech pathsbut also allows the recorder to monitor the signals on the paths.

The recorders 4 are also connected to a local area network such as anethernet (7) over which they communicate with other components of thesystem and can receive data for storage along with the voice data thatthey are recording from the speech paths (3). This data can be providedby any application on the network such as central business applicationsrunning on servers 6 or on an end user's desktop 10.

A server 5 consolidates details of all calls recorded by the recorders 4which may be scattered across a local or wide area network and maintainsa central database of “call records” which can be searched usingstandard SQL techniques. This also maintains details of the currentlocation of removable media and the calls they contain.

Also running on a server 5 as part of the recording system is typicallyan application, for example UNIFY, which interprets Computer TelephonyIntegration (CTI) data from the telephony switch 1. This information isused to control the recorders 4 and indicate when to start and stoprecording on both the speech and data channels. This information is alsoused to “tag” the calls with information regarding the call, such aswhich extension 8 the call was directed to. The recording of the datastreams can also be controlled by this application and these too can betagged with additional detail, such as which desktop 10 they relate to.Additionally, data stream recordings can be tagged with the identifierof the speech call that is in progress on the same desktop. For example,data from desktop 10 would be tagged with the identifier of theextension 8 on that desktop.

The voice and data calls that have been recorded can be retrieved byapplications running on PCs on the network 11. These applications searchthe call-details database held on the server 5 to determine whichcall(s) they wish to replay and where these calls are currently held.The call content is then requested from the recorder holding the disk,tape or optical media on which it has been stored.

The following components of an overall system are currently availableand are used as an underlying platform on which the specificenhancements used to provide the benefits described above can bedeployed.

Multimedia Stream Recorders

The recorder (4) is an example of a multi-channel voice recordercapable, of storing up to 128 conversations simultaneously. FIG. 2 showsthe relevant details of the recorder. The speech signals are presentedvia a high impedance tap 12 and are typically compressed by anappropriate line interface card 14. At regular intervals the blocks ofdata to be stored are passed via the internal data recording interface16 for indexing and storage to hard disk 18, or optionally, DigitalAudio Tape (DAT) media for longer term archive. Calls can be “tagged”with arbitrary data fields describing the call and subsequentlyretrieved for replay or analysis. In addition to recording voice calls,the recorder can record data streams representing arbitrarycommunication types. Examples include PC screen capture recordings,messages for display on underground trains in-cab displays etc. Theseare typically presented as Internet Protocol (IP) packets via anethernet cable 13 connected to an appropriate Network Interface Card(NIC) 15. The contents of these packets are passed through the sameinternal storage API 16 for storage to disk.

Computer Telephony Integration (CTI) Control and Tagging

The UNIFY component mentioned above is used to interpret one or moredata streams typically provided by telephony switches, Automatic CallDistributors (ACDs) or applications within a call centre. By passing theinformation flows from these and applying customers defined rules, theUNIFY component will control the recorders to start, stop, pause, resumeor break recordings on specified voice and/or data channels and/or to“tag” recordings, current or past, with specified data. These datafields ultimately form part of that recording's call detail record andcan later be used to search for it.

Enterprise-Wide Recording and Retrieval Services

E-Ware is an example of a suite of NT 4.0 applications which manage oneor more recorders to provide, across the customer's local or wide areanetwork, an enterprise-wide set of recording and retrieval services.Application Programming Interfaces (APIs) provide access to recordingcontrol, configuration, status monitoring, search and retrievalmechanisms. The system consolidates the call detail records from all therecorders in the system into a central, open relational databaseallowing queries of arbitrary complexity to be performed using SQL.Additionally, the system records the contents and current location ofall removable media to which calls have been recorded.

Data Recording System

One of the APIs of systems such as E-Ware provides for data recordingcapabilities and can be used by screen capture mechanisms.

The generic data recording API 21 is implemented for example by Eware2DR.DLL on Windows platforms and allows applications 19 to:

-   -   register data streams as being available for storage;    -   start and stop recordings on such data streams with the data        being transferred across the network 23 via IP packets formed by        an IP protocol stack 22 and ultimately stored on the recorders        (4);    -   provide their own timing information within the data stream        supplied or have the system automatically package the data        inside a protocol that adds time information at the required        level of accuracy and granularity.        Replay Application

Windows applications such as “Replay Studio” can be provided that allowa user to:

-   -   specify search criteria and perform searches to select a        required set of call details from the central database;    -   view the results of these searches in tabular and/or graphical        formats;    -   retrieve the contents of selected calls from the recording        system for delivery to a local or shared cache area for        subsequent replay; and    -   replay one or more selected calls in a way appropriate to the        type of call. Examples are voice calls played via a soundcard        and screen capture calls replayed in an on-screen window.

The application consists of an ActiveX framework into which additionaldata visualisation and replay mechanisms can be added to support newcall types.

Call Flow Recordings (CFRs)

The particular features related to this embodiment of the invention areas follows. The main purpose of these enhancements is to provide a CallFlow Recording (CFR) that details—to the level of detail required for agiven application—the progress of a call through the system this CFR isnot a database record but is actually a recording of a real-time datastream that allows the progress of the call to be reconstructedincluding both the route it took through the call handlingprocess—potentially down to the individual key-strokes entered—and wheneach step occurred.

These CFRs are stored within the generic recording system as “calls” ofa new, well-known, Format type. This allows the retrieval and replaytools to recognise them and display them appropriately as opposed totrying to replay them as audio calls. The format identifier used ischosen to be in the range reserved for variable bit rate streams.

These CFRs are tied to the other components of the call, such as voicerecording and screen content record, by use of cross-reference fieldswithin their call detail records. Each CFRs call detail record includesthe globally unique reference number of the “parent” call—typically avoice recording—to which it refers.

Additionally, “Parent” and “Child” flag fields can be used within thecall detail records to alert applications to the fact that the voicecall in question has one or more associated “calls” and, conversely,that the CFR has a related parent call and should not be viewed inisolation.

An alternative embodiment merges the context or progress informationwith the main recording so that the recorded data stream is an amalgamof the original plus the state information. A simple packetisationprotocol allows the combined stream to be decoded into blocks oforiginal and additional state information. This packetisation protocolmay be further extended so as to include many different data streamswithin the single file. Any one or more of these streams may beextracted from the whole for subsequent analysis or replay.

Explicit Context Notification

Where applications involved in the progress of calls through the callcentre are required to explicitly advise the recording system of thecall's current state, this can be achieved by using an API which islayered on top of the generic data recording API. This “Call FlowRecording API” (CFR-API) provides the following functionality:

-   -   it advises that the call is entering stage N, and offers user        definable parameters P1. . . Pn associated with this transition        which are typically the name of the stage;    -   it advises that the call is leaving stage N, and offers user        definable parameters P1. . . Pn associated with this transition        which are typically the name of the stage; and    -   it advises that the event E that is occurring e.g. a sale being        made, and offers user definable parameters P1. . . Pn associated        with this transition, for example the value of the sale).

It should be noted that several levels of detail can be stored sincecalls can enter multiple stages without leaving a higher level one. Forexample, a sales call may generate the following calls to the API as itis handled:

-   -   entering Customer Identification Stage;        -   entering Name Determination Stage;            -   entering Surname Determination Stage;            -   leaving Surname Determination Stage;            -   entering FirstName Determination Stage;                -   entering HelpScreen;                -   leaving HelpScreen;        -   leaving FirstName Determination Stage;    -   leaving Name Determination Stage;    -   entering Address Determination Stage; and    -   leaving Address Determination Stage.        Implicit Context Determination

In some cases it may be that not all of the applications involved in thehandling of calls will be enhanced to provide the above-mentionedexplicit notification of call progress. In such cases it may benecessary to infer the progress of the call from other sources such asscreen capture, network (e.g. ‘web’) traffic and/or speech analysis ofthe voice records.

In such cases, these other data streams may be used as more or lesssatisfactory proxies for the missing or incomplete call flow recording.Three examples of how call progress can be inferred are given below.

These inferred call flow elements may be analysed in real time andmerged into the overall call flow recording or may be determined at alater date by retrieving the data recording from which they are to beextracted.

First, the progress can be inferred from the key-strokes entered. As theentry of data via the keyboard is such a common and essential part ofmost call handling, keystrokes can be, by default, recorded as anintegral-part of the call flow recording for a given workstation. Thisis performed using standard Microsoft Windows “hooks” that allowapplications to intercept all keystrokes. The related data is thencombined into the same recording as the explicit notifications. Ineffect, these provide the lowest level of granularity within the callflow recording, for example, appearing as:

-   -   entering FirstName Determination Stage;        -   KeyHit=“F1”;        -   entering HelpScreen;            -   KeyHit=“Esc”;        -   leaving HelpScreen;        -   KeyHit=“T”;        -   KeyHit=“o”;        -   KeyHit=“m”; and    -   leaving FirstName Determination Stage.

The second means of inferring call progress relates to mouse clicks. Aswith keystrokes, mouse clicks and mouse movements can be sensed bydefault and inserted into the call flow recording. In addition to thebasic action being performed, the co-ordinates on screen and as muchdetail as possible about the underlying control or application arerecorded.

Thirdly, although determining call flow by analysing the display onscreen can prove quite complex and unreliable, in some cases it canprove advantageously simple and precise. For example, where screencapture is performed via Graphical-Device-Interface (GDI) callinterception, an “Order Entry” stage may be defined as when focus isplaced on the window with the caption “Order Processing System”.

Fourthly, whilst the discussions above have focused primarily on voicecalls, the same principles and methods apply to visits by customers to aweb site. The progress of the visitor around the web site and theanalysis of the activities they are engaged in, such as browsing andcompleting payment details, can be stored in exactly the same way as theprogress of the voice call is tracked. In these cases, the web servermay give explicit notification of call progress and/or this may beinferred from the web traffic being exchanged between the server and thevisiting customer.

Finally, where speech recognition software is deployed, either inreal-time, or later on the retrieved recordings, the words that itrecognises can be treated as a further, albeit “fuzzy”, means ofdetermining the progress of the interaction. For example, recognising“Visa” gives a good indication that payment details are underdiscussion.

Real-time Control of Recording

The architecture arising from the present invention allows for datastreams to be recorded and/or acted upon to control the real-timeactions of the system through the aforementioned UNIFY call controlcomponent.

The call progress streams can therefore be treated as both a stream tobe stored and a stream to be acted upon. Using the parsing mechanismsinherent within UNIFY, specific portions of the call that will start,stop, pause, resume, break or tag the recordings of the maincommunications streams can be identified.

Search Mechanisms

Customizable forms are provided with which the user can specify theparameters and criteria that are to be used to select a set of calls foranalysis and visualisation. The user may then choose to play the call(s)selected or to view their progress in any of the ways described below.

The search specification mechanism allows the user to specify:

-   -   any required combination of call detail record parameters, for        example call start time, campaign, wrap-up code. These can        ultimately be expressed in, for example, an SQL “WHERE” clause;        and    -   one or more call flow parameters including one or more criteria        of the following forms:        -   calls passing through one or more specific point in the call            flow diagram a specified number of times (including zero);            and        -   calls spending more or less than a specified time between            specified points in the call flow diagram.

As users refine their search criteria, it then becomes possible to applythe new criteria to:

-   -   the set of all calls;    -   the results of the previous search; and    -   the results of any earlier search.

The search itself is performed as a combination of SQL query statementsselecting the set of calls that satisfy the requested call detailparameters and a process whereby the call flow record of each of thesecalls can be retrieved and analysed to determine whether or not the callsatisfies the call flow criteria specified.

An optimisation of the above allows for more rapid responses to suchsearches by recording the results of commonly performed call flow recordanalyses and storing the results of these analyses in database tableswhich can then be searched efficiently using SQL queries when the systemrecognises one of these common search requests.

Data Visualisation Methods

Several different approaches can be used to show the call flow. Each isappropriate to a particular form of analysis or reason for using thetools. For example, a call “storyboard” can be created. Traditionally,when a call was selected for replay, a simple “slider-bar” was displayedhaving a pointer moving from left to right as the call is replayed. Morerecently, the waveform of the recording has been illustrated and silentperiods highlighted. Periods of interruption and, where screen capturehas been performed, the volume of on-screen activity occurring over theduration of the call has also been included in the display.

With the addition of a call flow recording, the display illustrated inFIG. 4 can be further enhanced with coloured bars indicating theprogress of the call through various stages and sub-stages; pop-up textdescribing each stage should the user point at one of the bars; andicons signifying events during the call—including data entry.

An example of these elements as would be overlaid on the voice andscreen capture waveform displays is shown in FIG. 4 with pop-up textexplaining the bar being pointed to. The progress of the call is shownwith the icons representing:

Icon Meaning Handshake Customer greeting - standard salutation BombCustomer raises complaint Dove Complaint resolved successfully Openhands New product offering explained and offered Gavel Pricenegotiations Tick Agreement to buy Money bag Payment terms agreed PostPigeon Delivery details agreed

Graphical displays such as those shown in the top-level call flowdiagram FIG. 5 are used to show the user the progress of one or moreselected calls through the various stages of the call handling process.

Specific features of such displays include nodes labelled to indicatethe activity in progress, nodes coloured to highlight groupings (e.g.sales v service) and/or nodes shaped to distinguish between e.g. thosewith sub-structure within them that can be viewed by double-clicking onthe node—as shown in “Basic Fault Finding” node, colours to highlightdesirable/undesirable outcomes (e.g. abandoned call node), lines betweennodes to show the flow of calls from one stage to another, thickness oflines proportional to the number of calls following this path, linesbeing coloured to highlight unexpected routes as in the backtrackingfrom delivery details to payment details discussed below, dashed linesused to highlight available but unused paths, and nodes sized toindicate the total time spent in this particular stage of the call flow.

The example shown in FIG. 6 is a “drill-down” to finer detail within the“Basic Fault Finding” node of the previous diagram. In this example, theuser has double clicked on the top level node to examine the detailedflow within the top-level node. This example shows by means of thedotted line, a possible call flow route that none of the selected callstook. In this case, the user might reconsider the value of the “MainsLead” question since it did not resolve any of the selected calls.

Drill-down to Subset of Calls

By double clicking on one of the lines, the user can select the sub-setof calls that went via that route. The other lines in the diagram arethen redrawn to show the rest of the call flow route taken by theseparticular calls.

Dynamic Call Flow Diagrams

Such diagrams may be static, for example showing the overall call flowfor the selected set of calls. Alternatively they may be dynamic, inwhich the lines are added and grow thicker in real time as calls areshown to move through the call flow at N times real-time. This allowsusers to see bottlenecks, delays and unusually sluggish or speedy calls.

The speed at which the diagram populates can be adjusted to n timesreal-time where n may be 0 (paused), or a positive value or negativei.e. “rewind” value. When paused, a “single-step” mode can be invoked inwhich each subsequent stage of the call is shown on demand or after afixed time regardless of the actual time it took at the time ofrecording.

It should be appreciated that the invention is not restricted to thedetails of the foregoing embodiment, the particular features of whichare merely illustrative.

1. A communications recording and analysis system comprising: means forrecording one or more communication streams; means for identifying thestreams recorded; means for retrieving the content of said recordings byidentifier tags, wherein additional real-time information relating tothe progress of the said communication streams is recorded such that thecommunication streams and the real-time information are interleaved andprovided as an integrated real-time data stream; and means for allowingidentification and subsequent retrieval of sub-sections of a recordedsegment of a communication stream for analysis.
 2. A system as claimedin claim 1, wherein the communication streams and associated progressstreams are linked by means of a cross reference within respective calldetail records in a database of recordings.
 3. A system as claimed inclaim 1, and arranged such that, the progress information is inferredfrom analysis, in real-time or later, of keystrokes entered at acomputer/terminal handling the interaction.
 4. A system as claimed inclaim 1, and arranged such that the progress information is inferredfrom analysis, in real-time or later, of computer mouse actions.
 5. Asystem as claimed in claim 1, and arranged such that, the progressinformation is inferred from analysis, in real-time or later, ofinternet traffic emanating from, or terminating at, any one or more of anumber of computers/terminals handling the interaction.
 6. A system asclaimed in claim 1, and arranged such that the progress information isinferred from analysis, in real-time or later, of the words and/orprosody spoken during the interaction.
 7. A system as claimed in claim1, and arranged for the retrieval of specific sets of recordings throughselection from the call detail records describing each of the recordingsand/or the presence, repeated presence or absence, of specified eventsor call states.
 8. A system as claimed in claim 1, and includinggraphical display means for the display of the content of individualrecordings.
 9. A system as claimed in claim 8, wherein the graphicaldisplay means is arranged such that the location, colour and/or size ofdisplay elements is determined by the recorded call flow recording. 10.A system as claimed in claim 8, wherein the graphical display means isarranged such that the presentation of one or more call flow recordingsis in the form of a directed graph showing the progress of the callsthrough the various states and transitions.
 11. A system as claimed inclaim 8, wherein the graphical display means is arranged to bepopulated, and the graphical attributes modified, in real-time toreflect the timing information recorded within the call flow recordings.12. A system as claimed in claim 8, wherein specific elements of thedisplay are arranged to be emphasized according to defined rules so asto draw attention to the presence or absence of particular call flowroutes.
 13. A communications recording and analysis system comprising:at least one recorder operative to record voice information associatedwith a communication, screen content information associated with thecommunication, and input/output information associated with thecommunication and with a computer from which the screen content wasacquired; and a first computer application operative to access the voiceinformation, the screen content and the input/output information and toconstruct an integrated real-time data stream comprising the voiceinformation, the screen content information and the input/outputinformation; wherein the integrated real-time data stream is configuredto enable progress of the communication to be reconstructed such thatscreen content information and input/output information is correlatedwith the voice information of the communication.
 14. A system as claimedin claim 13, wherein the input/output information comprises at least oneof: keystrokes entered at the computer; computer mouse actions enteredat the computer; and internet traffic emanating from, or terminating at,the computer.
 15. A system as claimed in claim 13, further comprising: asecond computer application operative to analyze the informationcontained in the integrated real-time data stream and to automaticallyscore at least a portion of the communication that was recorded.
 16. Asystem as claimed in claim 13, further comprising: a second computerapplication operative to automatically and selectively perform voicerecognition analysis on a portion of the voice information contained inthe integrated real-time data stream.